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^ (57) Abstract: 1) A method for synchronizing databases (DB1, DB2), a first database (DB1) being stored in a first data processing 
<^t- system (MOB), a second database (DB2) being stored in a second data processing system (MNO), said method comprising: a. A 
O loading step in which an application (APP) is loaded into said first data processing system (MOB); b. An execution step in which 
O the application (APP) executes a command; c. A requesting step in which said command requests the first data processing system 
^ (MOB) to process a synchronization step, said command providing the first data processing system (MOB) with the information 
Q about the synchronization parameters to be used for synchronizing the content of the first (DB1) and the second (DB2) databases, 
^ said method being characterized in that said first data processing system (MOB) includes a security token (CAR) controlled by an 
operator (OP) and in that said application (APP) is loaded into said security token (CAR). 
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DATABASES SYNCHRONIZATION 

Field of the Invention 

5 The invention deals with synchronization of databases. Data synchronization is 

the act of establishing equivalence between two data collections, where each data 
element in one item maps to a data item in the other, and each item and its respective 
mapping having a content which is equivalent. 

10 Prior Art 

The existing technology allows Terminal Equipments to exchange and to 
synchronize data with an external device. The way that a synchronization process is 
requested depends on the protocol used, which is based on the capabilities of the 
15 terminal equipment. 

US 6, 505,215 discloses a method for synchronizing databases, a first 
database being stored in a first data processing system, a second database being 
stored in a second data processing system, 

said method comprising: 
20 a. A loading step in which an application is loaded into said first data 

processing system; 

b. An execution step in which the application executes a command; 

c. A requesting step in which said command requests the first data processing 
system to process a synchronization step, said command providing the first 

25 data processing system with the information about the synchronization 

parameters to be used for synchronizing the content of the first and the second 
databases. 

In this prior reference, the first data processing system is a small 
30 microprocessor based computer system such as a cellular phone or a handheld 
personal information manager. 

This invention particularly applies to security tokens such as smart cards, 
potentially equipped with a subscription related application provided by a service 
35 provider or network operator. This application can be indifferently a SIM (Subscriber 
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Identity Module), a USIM (Universal Subscriber Identity Module), a RUIM (Removable 
User Identity Module) or any emergent smart card application managed/controlled by 
an entity such as an operator. 

5 If an operator wants to create his own data synchronization applications (e.g. 

to provide management procedures linked to synchronization process), some 
important facts shall be considered: 

-The operator does not own the terminal equipment. It is owned by the user 
10 (see the reference cited above). 

-Most terminal manufacturers do not provide standardized capabilities to 
implement customizable applications in their terminals. 

15 -Applications present in the terminals are not controlled by the operator (see 

also the above cited reference). 

-There is a standardized way to update/download applications in the card. 
20 The Invention 

The main objective of the invention is to apply the technology known by the 
above mentioned prior document to the control of the synchronization processes of a 
mobile equipment using a security token thereby rendering the process easier and 
25 more reliable, in particular in the field of security. 

The invention has therefore as an object a method of the kind defined here 
above characterised in that 

said first data processing system includes a security token controlled by an 
30 operator and in that said application is loaded into said security token. 

In this way, the command will operate as an interface between the application 
and the synchronization capabilities of the User Equipment. 

The card is owned and controlled by the operator. Moreover, the card 
35 applications can interact with the terminal, the user, and the network by means of 
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existing "Card Application Toolkif commands. In this way, according to the invention, 
the synchronization process is initiated by the card and not the mobile phone. This 
new command is added within the Card Application Toolkit that can be launched 
either locally by the user or a special application, or either remotely by the operator via 
5 the existing OTA (Over The Air) process. So, the invention can be applied to allow a 
user or a card application to command the execution of a data synchronization 
process between a UE (User Equipment) and an external entity. A User Equipment is 
a device allowing a user access to network services. The User Equipment is at least 
composed of a terminal equipment (e.g. a mobile equipment) and a smart card. 

10 

In our example, this new command will send to the mobile the information 
needed to perform the synchronization: source device, destination device, used 
synchronization protocol, used transport layer, type of synchronization and database 
to synchronize. 

15 

It will be easier to understand the invention on reading the description below, 
given as an example and referring to the attached drawings. 

In the drawing: 

20 

Figure 1 is a block diagram view of the architecture of a computer system on 
which the solution can be applied. On this figure appear some arrows illustrating 
different steps of the invention. 

25 Detailed description of examples illustrating the Invention 

A Mobile Network Operator (MNO) implements a device management system 
consisting in the following components (see figure 1): 

30 

-A database DB1 in the mobile (MOB) containing a list of basic parameters 
(i.e. IMEI, used language, sounds, etc..) and a list of applications and games that are 
installed in the device together with their operating parameters (version, size,...). This 
database is called Local Device Management Database. In another example, this 
35 database should have been stored in the SIM card itself. 
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-A copy of this database DB2 in a MNO's server. Let us call this database 
MNO's Device Management Database. 

5 -A device management application in the SIM. This application is controlled 

and managed by the MNO. The application is in charge of analysing different 
parameters (e.g. time that the equipment has been connected) and can dialog with 
the MNO through a secured channel. 

10 Thanks to the command in the card Application Toolkit, following the MNO's 

synchronization policy, the SIM application is able to ask the mobile equipment to start 
a synchronization process of his Local Device Management Database with the MNO's 
Device Management Database. 

15 This synchronization can be summarized as follows: (see f ig.1 ) 

A. The MNO installs a device management application in the subscriber's SIM. 
The MNO may update this application or modify any parameters used since 
this is completely controlled by him through a secured communication channel. 

20 

B. The card CAR is informed of different events that may occur in the mobile 
equipment or in the network. The device management application may be 
informed of these events. This may include data regarding terminal 
capabilities. 

25 

C. Following the MNO's policy contained in the device management 
application and considering the events and/or messages received, the device 
management application may conclude that a synchronization of the Mobile 
Local Database with the MNO's Device Management Database is needed. 

30 

D. The device management application uses a new command in the 
card application toolkit "Request Synchronization". This command informs the 
mobile that a new synchronization is requested. In a preferred embodiment, 
the device management application gives to the mobile synchronization agent 
35 the following information: 
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- synchronization protocol: Synchronization protocol that should be 
used. (e.g. SYNCML) 

- session/transport laver Transport or session layer that should 
be used (e.g. WSP) 

- type of svnchronization :Type of synchronization that should 
be used (e.g. refresh from the client) 

- Source database : Unique Identifier of the local database in the client. 
Containing: 



i. device : identifier of the device containing the source 
15 database (e.g. IMEI of the mobile equipment ) 

ii. database : identifier of the database (e.g. an URL of the 
Local Device Management Database) 



10 



20 - Target database : Unique identifier of the database in the server to be 

synchronized. Containing: 

i. device : identifier of the device containing the target 
database (e.g. URL of the MNO's server ) 

25 

ii. database : identifier of the database (e.g. an URL of the 
MNO's Device Management Database) 

- Notification: Whether the Application shall be notified of the final result 
30 of the synchronization, (e.g. No notification requested) 

E. The Mobile equipment receives all the parameters. The mobile is now able 
to initiate a synchronization process using the information given in the "Request 
synchronization" command. Synchronization is performed between the Local Device 
35 Management Database in the mobile and the MNO's Device Management Database 
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in the MNO's server. Advantageously, a program is able to receive all the parameters 
and to activate the synchronization process. 

F. The card device management application may be informed of the 
5 synchronization results if this was requested in the previous "Request 
synchronization n command. 

This controlled synchronization may permit the MNO to offer different services 
to their subscribers and to perform various management functions. For example, 
10 knowing what is the version of an application currently installed in the mobile device, 
MNO is able to propose an available upgrade. 

To be noted that the source database may be any database that can be 
accessed by the mobile equipment including databases (files, applications,...) of the 
15 SIM. This database can be indifferently located in the card CAR or in the mobile 
equipment MOB. 

To be also noticed that the application in the card could use the card 
application toolkit functionalities to interact with other entities (e.g. the user). In this 
20 case, for instance, the user may be prompted before the synchronization command is 
sent, or it could be informed after the successful synchronization had taken place. 

In the claims, said mobile equipment is more generally called first data 
processing system. In the same way, said server is called second data processing 
25 system. 
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Claims 

1) A method for synchronizing databases (DB1, DB2), a first database (DB1) 
being stored in a first data processing system (MOB), a second database (DB2) being 

5 stored in a second data processing system (MNO), 
said method comprising: 

a. A loading step in which an application (APP) is loaded into said first data 
processing system (MOB); 

10 b. An execution step in which the application (APP) executes a command; 

c. A requesting step in which said command requests the first data processing 
system (MOB) to process a synchronization step, said command providing the 
first data processing system (MOB) with the information about the 
15 synchronization parameters to be used for synchronizing the content of the 

first (QB1) and the second (DB2) databases, 

said method being characterized in that 

said first data processing system (MOB) includes a security token (CAR) 
20 controlled by an operator (OP) and in that said application (APP) is loaded into 

said security token (CAR). 

2) The method according to claim 1, characterized in that the information 
includes the identifier of the database (DB2) to be synchronized. 

25 

3) The method according to claim 1, characterized in that the information 
includes the synchronization protocol to be used between the 1 st and 2 nd data 
processing systems. 

30 4) The method according to claim 1, characterized in that the information 

includes the identifier of the first database (DB1). 

5) The method according to claim 1, characterized in that the first data 
processing system (MOB) is a mobile apparatus coupled to a smart card. 
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6) The method according to claim 1, characterized in that the application is 
informed of the synchronization result between the 1 st and 2 nd databases. 

7) The method according to claim 1 or 6, characterized in that the application 
5 is informed of the synchronization result if this was requested in the command. 
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